前一篇提到，我會先在 Worktree 裡確認這份 change 的修改，再把它合回主要 branch。不過，tasks 全部打勾，只表示清單上的工作已經標記完成。功能有沒有照規格做、code 裡有沒有藏著 Bug，還是需要另外檢查。
【Day - 9】介紹過的 Verify，就是用來核對實作與規劃文件，Spectra 也延續了這個用途。我在 Speclink 沿用 Verify 之後，還想讓 AI 幫忙看看程式碼本身有沒有問題，因此後來補上了 Review。這個想法，和我逐漸跟不上 AI 寫 code 的速度有關。
【Day - 1】提過，進入 AI Agent 的階段後，一天新增、修改好幾萬行 code 都有可能發生。這個產出速度早就超過我逐行 review 的速度；如果每一行都要自己完整看完，最後的瓶頸就會變成我。
偶爾我還是會打開 diff，看看需要特別注意的程式碼，或確認某段功能最後是怎麼做的。至於其他地方，老實說就真的處於放生狀態了XD。
完全靠自己看不完，全部不看又有點可怕！能不能讓 AI 從不同角度各檢查一次，再把需要注意的地方整理給我呢？
剛好就在前面提過的 grill-me 很紅的那段時間，我也開始翻 Matt Pocock 提供的整套 Skills。除了【Day - 15】、【Day - 18】談過的提問方法，他的技能包裡還有一個 code-review Skill（裡面真的很多東西可以挖XD）。
和 grill-me 一樣，我沒有實際安裝使用這份 Skill，不過有看 Matt Pocock 的影片、其他人的介紹與官方內容。它會先確認這次要看的 diff，再交給兩個 sub-agents 平行檢查：Standards 看 code 是否符合專案規範，Spec 則核對這次修改是否符合需求。
sub-agent 可以先理解成由主要 AI Agent 分派出去、負責一項工作的子 Agent。這裡兩個子 Agent 都只讀取內容、回報問題，不直接修改 code：
兩邊的結果會分開列出。假設 code 寫得很整齊，卻把功能做錯了，Standards 可能沒有問題，Spec 還是會指出需求沒有做到；反過來，功能雖然做對了，也可能留下重複、難讀或難維護的寫法。分開呈現後，就比較容易看出問題出在哪裡。
其中讓我感興趣的，是 Standards 除了會讀取專案自己的 coding standards，還有 12 項基本的檢查方向。根據 Matt Pocock 的說明，它們來自 Martin Fowler 的《重構－改善既有程式的設計》第 3 章 code smells（程式碼的壞味道）。Skill 從裡面挑出 Mysterious Name、Duplicated Code、Feature Envy 等項目，讓專案即使沒有另外寫 coding standards，也有一些可以先檢查的地方：
不過，這些規則只是提醒「這裡可能有問題」，仍然要看實際情況，不能看到其中一項就判定 Review 失敗。如果專案已經寫下明確規範，也會以專案自己的規範為準。
這套分工給了我不少靈感。但 Speclink 已經有 Verify，直接把兩種檢查都搬過來，會不會和原本的工作重複？
Matt Pocock 的 Spec 檢查會核對修改是否符合需求，這件事已經由 Speclink 的 Verify 負責。所以，我和 AI 討論後，決定保留 Standards，把另一項改成 Correctness，專門找程式邏輯本身的問題：
| 檢查方向 | Speclink Review 會看什麼？ |
|---|---|
| Standards | 是否符合專案規範，以及有沒有值得注意的 code smells。 |
| Correctness | 邊界情況有沒有漏掉、出錯時能不能正確處理，以及資源使用或同時執行時會不會出問題。 |
Verify 也有一項叫 Correctness，但問的是「功能有沒有照規格做」。Review 則會追問程式本身是否有 Bug，即使 specs 沒有寫到那種情況，也可能提出問題。兩邊的分工可以放在一起看：
現在有什麼不同？ Spectra 3.0.0 也加入了 review，會先讀 change 的規劃文件，再檢查實作的 code 品質。它只出報告，不直接改 code，並且會說明每項問題是違反專案規則，還是審查者根據程式碼做出的判斷。verify 則繼續負責核對實作與規格。
開始 Review 時，Speclink 會先確認這次 change 要檢查哪些修改，再交給 Standards 與 Correctness 兩個唯讀 sub-agents。它們也會讀取 change 的規劃文件，了解這次修改想完成什麼，但不會逐條核對規格。
檢查後提出的問題與建議，統稱為 findings，會整理進 review.md。需要修正時，再回到主要 session 處理 code。不過，修完之後該怎麼檢查，我後來又遇到另一個問題。
我實際遇過，每次重新掃描同一批 code，AI 都會再找出新的 smell 或 Bug；當時甚至連跑三輪，最後累積了 38 筆 findings。上一輪的問題才修好，下一輪又冒出別的問題，不只消耗 Token，也很難知道到底什麼時候才算結束。
因此，我後來把完整檢查限制在第一輪。修正後再檢查一次，也就是複驗時，只確認原本的問題有沒有修好，以及這次修正有沒有直接帶進新的 Bug。如果必須處理的問題沒有繼續減少，就先停下來，不會一直重試。
符合收尾條件後，才會留下 Review stamp（審查章），記錄這次檢查已經完成。這不要求所有改善建議都做完；哪些問題必須先處理，會在後續介紹收尾時一起說明。把檢查與修正放在一起，流程如下：
有了 review.md，換個 session 也能知道前面找到哪些問題，再接著修正與複驗。做到這裡，我很快又想到：Verify 找到規格缺口後，不是也需要同樣的紀錄嗎？
所以，我把這套方式也帶進從 Spectra 沿用下來的 Verify。原本的三個檢查方向保留下來：Completeness 看有沒有做完，Correctness 看有沒有照規格做對，Coherence 則看實作與設計是否一致。
Speclink 會先確認這次要檢查的修改與檔案，再把三個方向交給一個唯讀 sub-agent。找到的問題寫進 verify.md，需要修正時，仍然回到主要 session 處理。這樣大量閱讀與核對的工作就能分出去，不必全塞在主要對話裡。
和 Review 一樣，第一輪完整檢查，後續只確認原本的 findings 與修正直接造成的新問題。換個 session 後，AI 也能從 verify.md 裡尚未處理的項目繼續，不用再靠我重講一次：
符合收尾條件後，Verify 也會留下自己的 stamp。兩個章分別記錄各自完成的檢查，不會因為其中一個完成，就一起把另一個標成完成。
這裡用 tasks 打勾後的情況來說明，並不是說一定要等整份清單都勾完才能檢查。前面提過的 [M] 人工驗收，也不一定要先完成；如果那項人工工作會擋住後續實作，則仍然要先處理。
這兩個流程都可以依照修改的風險與需求選擇。想核對功能是否照規格完成，就跑 Verify；想找 code 裡的 Bug 或難維護的寫法，就跑 Review。可以只跑其中一個、兩個都跑，或這次都不跑，並不是每份 change 都必須固定走完兩道檢查。
不過，兩個都要跑時，還有一件事要注意。如果先完成 Review，Verify 後來又找出問題，修正了 code，前面的 Review 還能代表現在這份內容嗎？
接下來，我們就看看這些檢查結果怎麼留下來，以及 code 改過之後，兩個流程要怎麼一起收尾吧！
code-review Skill
iThome鐵人賽
看影片追技術